1. Field of the Invention
The present invention generally relates to data base management systems and more particularly relates to enhancements for protecting access to various components by scripted legacy data base management systems via the Internet.
2. Description of the Prior Art
Legacy data base management systems are well known in the data processing art. A data base management system is termed “legacy” because its non-object oriented basic design and implementation predate the various current design and protocol standards which permit integration with other more modern object oriented systems. Such commercial legacy systems have been in general use for more than 20 years. One of the most successful legacy data base management systems is available from Unisys Business Information Systems (BIS) and is called the Classic MAPPER□ data base management system. The Classic MAPPER system can be reviewed using the Classic MAPPER User's Guide which may be obtained from Unisys Corporation.
The Classic MAPPER system, which runs on proprietary hardware also available from Unisys Corporation, provides a way for clients to partition data bases into structures called filing cabinets and drawers, as a way to offer a more tangible format. The MAPPER data base manager utilizes various predefined high-level instructions whereby the data base user may manipulate the data base to generate human-readable data presentations called “reports”. The user is permitted to prepare lists of the various predefined high-level instructions into data base manager programs called “MAPPER Runs”. Thus, users of the Classic MAPPER system may create, modify, and add to a given data base and also generate periodic and aperiodic reports using various MAPPER Runs.
However, with the Classic MAPPER system, as well as with similar legacy data base management systems, the user must interface with the data base using a terminal coupled directly to the legacy system and must access and manipulate the data using the MAPPER Run command language of Classic MAPPER. Ordinarily, that means that the user must either be co-located with the hardware which hosts the data base management system or must be coupled to that hardware through dedicated telephone, satellite, or other data links. Furthermore, the user usually needs to be schooled in the scripted command language of Classic MAPPER (or other legacy data base management system) to be capable of generating MAPPER Runs.
Since the advent of large scale, dedicated, legacy data base management systems, the Internet or world wide web has come into being. Unlike closed legacy data base management systems, the Internet has become a world wide bulletin board, permitting all to achieve nearly equal access using a wide variety of hardware, software, and communication protocols. Even though some standardization has developed (e.g., object oriented script), one of the important characteristics of the world wide web is its ability to constantly accept new and emerging techniques within a global framework. Many current users of the Internet have utilized several generations of hardware and software from a wide variety of suppliers from all over the world. It is not uncommon for current day young children to have ready access to the world wide web and to have substantial experience in data access using the Internet.
Thus, the major advantage of the Internet is its universality. Nearly anyone, anywhere can become a user. That means that virtually all persons are potentially Internet users without the need for specialized training and/or proprietary hardware and software. One can readily see that providing access to a legacy data base management system, such as Classic MAPPER, through the Internet would yield an extremely inexpensive and universally available means for accessing the data which it contains and such access would be without the need for considerable specialized training.
There are several basic problems with permitting Internet access to a proprietary legacy data base. The first is a matter of security. Because the Internet is basically a means to publish information, great care must be taken to avoid intentional or inadvertent access to certain data by unauthorized Internet users. In practice this is substantially complicated by the need to provide various levels of authorization to Internet users to take full advantage of the technique. For example, one might have a first level involving no special security features available to any Internet user. A second level might be for specific customers, whereas a third level might be authorized only for employees. One or more fourth levels of security might be available for officers or others having specialized data access needs.
Existing data base managers have security systems, of course. However, because of the physical security with a legacy system, a certain degree of security is inherent in the limited access. On the other hand, access via the Internet is virtually unlimited which makes the security issue much more acute.
The second major problem is imposed by the Internet protocol itself. One of the characteristics of the Internet which makes it so universal is that any single transaction in HTML language combines a single transfer (or request) from a user coupled with a single response from the Internet server. In general, there is no means for linking multiple transfers (or requests) and multiple responses. In this manner, the Internet utilizes a transaction model which may be referred to as “stateless”. This limitation ensures that the Internet, its users, and its servers remain sufficiently independent during operation that no one entity or group of entities can unduly delay or “hang-up” the communications system or any of its major components. Each transmissions results in a termination of the transaction. Thus, there is no general purpose means to link data from one Internet transaction to another, even though in certain specialized applications limited amounts of data may be coupled using “cookies” or via attaching data to a specific HTML screen.
However, some of the most powerful data base management functions or services of necessity rely on coupling data from one transaction to another in dialog fashion. In fact this linking is of the essence of MAPPER Runs which assume change of state from one command language statement to the next. True statelessness from a first MAPPER command to the next or subsequent MAPPER command would preclude much of the power of Classic MAPPER (or any other legacy data base management system) as a data base management tool and would eliminate data base management as we now know it.
A third problem is the basic integration of the Microsoft Component Object Model (COM) scripting with non-object oriented legacy data processing system scripting languages. The principal means of solving this problem in the past involved invoking a separate application from within the script. Most scripting languages provide a means to execute an external program in the native Operating System (OS) environment in which the scripting engine runs.
For example, the script can synchronously execute a Windows console application or command file. This application would need to be developed using Microsoft development tools and a Microsoft programming language (e.g., Visual Basic) that is supported by Microsoft Corporation. This application would then function as an intermediary between the non-Microsoft scripting environment and the COM server. Overall, this broadens the required skills set of the developers, as they must be proficient not only in the non-Microsoft scripting language (i.e., scripting language of the legacy data base management system such as MAPPER), but the Microsoft language and tools required to build the proxy, as well. In general, this makes implementation of a generic COM client (i.e., one that allows usage of an arbitrary COM server) impractical.
Perhaps the greatest difficulty involved in client calls to COM servers concerns protecting the instantiating client against problems created by the instantiated COM server. Though instantiation of generic in-process servers tends to be more efficient, the problem is most acute, because of the lack of control of the server by the client. Typically, the client needs to be protected from corruption of its memory spaces and copying of sensitive information.
These risks may be manageable if the client application developer also is the developer of the in-process server(s) used by the client. If this is the case, at least the developer may debug the COM server to correct the problem in a timely manner. However, if, as is often the case, the client uses third party COM servers, the risk in using in-process servers is substantial. In these scenarios, the COM client developer has little control over the resolution of a COM server defect. This situation is almost impossible to effectively mange in the case where the client implements a generic COM client interface. The COM client software developer literally has no control over what COM servers are instantiated by the client, nor does he/she even know what servers are available to be instantiated at run time.
A case in point of this later scenario exists in a preferred embodiment of the present invention, Unisys Business Information Server (BIS) utilizing the Cool ICE system. The product implements a generic COM client interface in its proprietary scripting engine as explained in detail below. The product is sold to customers, who install it on their server(s) and then write script applications to suit their organizational needs. The Unisys Corporation product developers have no control or knowledge of what COM server(s) their customers will choose to incorporate into their BIS script-based applications. If the integrity of even one target COM server is questionable, it can result in serious support consequences in terms of financial cost, lost productivity, compromised sensitive data, and customer dissatisfaction.